Access Control on Objects

The following table describes the access control on objects, and their effect at the client side and the server side. It also shows how access control on objects determines access control on attributes.

Consider the first row in Table 1 and assume you have set the access mode for the entire object to "Hide". Accordingly, if you set the access mode of an attribute to "Read-write", then the access mode of the object at the server will be set to "Read". This is because the object-level access mode (in this case, "Hide") takes precedence over the attribute-level access mode. The "Hide" access mode does not apply to server-side objects (since Hide is specific to a user-interface), and therefore, the access mode translates to "Read". However, at the client-level, the access mode is set to "Hide".

Note: In composite objects, access modes can be set on the outer object and the inner object. The access mode that you set on the outer object will always take precedence over the access mode that has been set on the inner object.

Example

<purchaseOrder orderDate="1999-10-20">
    <billTo country="US">
        <name>Robert Smith</name>
        <street>8 Oak Avenue</street>
        <city>Old Town</city>
        <state>PA</state>
        <zip>95819</zip>
    </billTo>
    <shipTo country="US">
        <name>Alice Smith</name>
        <street>123 Maple Street</street>
        <city>Mill Valley</city>
        <state>CA</state>
        <zip>90952</zip>
    </shipTo>.
  .
  .
</purchaseOrder>

In the above object, PurchaseOrder is the outer object, and billTo is the inner object. Assume that you want to set the access mode for the PurchaseOrder object to "Read-only", and set the access mode for billTo object to "Read-write". The "Read-only" access that has been set on the outer object has greater precedence, and therefore, the access mode for the billTo object also is set to "Read-only".

Access Control on Attributes

The following table describes the access control on attributes, and their effect at the client side and the server side.

Case 1: Consider the first row in Table 2, where the availability of an attribute is set to "false". As a result, the attribute becomes "read-only" when accessed at the server level, and "hidden" at the client level.
Note: If availability of an attribute is set to "false", you cannot set its changeability or write access logic. Case 2: When the availability of an attribute is set to "True" and changeability to "AddOnly", it indicates that you cannot modify the attribute value once it is set. If the object contains a value, it will be "Read-only" at both the server and the client, even if you set the logic to "Read-write". However, if the object is empty, and you set the access logic to "Read-write", the object will have the "Read-write" state at both the server and the client.
Note: The changeability settings primarily determine the accessibility of an object at the server and the client.

Retrieving Access Control Information

When objects undergo constant change, it is necessary to review their accessibility information from time-to-time so that they are appropriate to the activity in which they participate and reflect correctly on the UI. You can retrieve the access control information of objects and attributes using a query, or an update, or a validate request. The response contains the access control information.

Before you send a request, include theqAccessattribute and set it to1.